The invention relates to synchronization of database data in a telecommunications system, particularly to maintenance of data on synchronization events. Data synchronization is a function where at least two data collections are made similar to each other so that the data units of the data collections substantially correspond to each other after synchronization.
Data of portable terminals, such as portable computers, PDA devices (Personal Digital Assistant), mobile stations or pagers, can be synchronized with network applications, applications of desktop computers or with other databases of the telecommunications system. In particular, data of calendar and e-mail applications are typically synchronized. EP 1 024 441 discloses a method of synchronizing databases. The method comprises maintaining data on the time the database has transmitted records to another database (transmission time), the time the database has received records from another database (reception time) and the time each record in the database has been modified (modification time). A record is transmitted from the first database to the second database only if the record modification time is later than the transmission time and the modification time is earlier than the reception time.
Synchronization has been based on the use of different manufacturer-specific protocols which are incompatible. This restricts the use of terminal or data types and often causes troubles to the user. In mobile communication, in particular, it is important that data can be retrieved and updated regardless of the terminal and application used.
To improve synchronization of application data, a language known as Synchronized Markup Language SyncML, which is based on the XML (Extensible Markup Language), has been developed. Using a SyncML synchronization protocol, which employs messages in the SyncML format, data of any application can be synchronized between networked terminals of any kind. The SyncML synchronization protocol functions both in wireless and in fixed networks and supports several transmission protocols.
FIG. 1 shows an example of synchronization where a mobile station MS functions as the SyncML client terminal and a network server S functions as the SyncML server. The SyncML synchronization service comprises first initializing a synchronization session during which e.g. the database to be synchronized is selected. The SyncML client terminal MS comprises a sync client agent which implements the SyncML protocol and sends a SyncML message (Client Modifications), which includes at least the data which are to be synchronized in the mobile station MS and have changed since the last synchronization. The SyncML server S comprises a sync server agent, which controls synchronization, and a synchronization block (Sync Engine). The server usually waits for an initiative for synchronization from the SyncML client (MS). The server S synchronizes the data, i.e. analyses the changes made to the database and client terminal data, and harmonizes it (makes necessary modifications, replacements and deletions). After this, the SyncML server S sends the server modifications back to the SyncMI client (MS). The example described above is simple; yet it illustrates the roles of the devices according to the SyncML standard. The SyncML client terminal (MS) is typically a mobile station (MS), a PC (Personal Computer), a laptop, or a PDA device. The SyncML server S is typically a network server or a PC.
The system according to the SyncML standard employs ‘synchronization anchors’ associated with databases. These are strings which describe a synchronization event in terms of the date and time, for example. The synchronization anchors used are called the ‘Last’ anchor and the ‘Next’ anchor, of which the Last anchor represents the last event when the database was synchronized in respect of the transmitting device and the Next anchor represents the present synchronization event in respect of the transmitting device. The devices transmit their anchors to each other during initialization of a synchronization session so that the Next anchor can be stored after a successful synchronization session. During the next synchronization the device can compare the Next anchor stored with the Last anchor received, and if they match, the device notes that no errors have occurred since the last synchronization. If the anchors do not match, it is necessary to perform slow synchronization, for example, where all data units in the databases have to be compared with one another. In practice, in slow synchronization the client terminal transmits all data from the database to be synchronized to the SyncML server, which analyses field by field the data it has received and the data of another database to be synchronized, or alternatively replaces all the data of the other database to be synchronized with the data it has received. In standard SyncML Sync Protocol, version 1.0, December 2000, which defines the SyncML synchronization protocol, it is stated that the synchronization anchors must not be updated until the synchronization session has finished.
FIG. 2 illustrates use of synchronization anchors. In this example the SyncML client (MS) and the SyncML server (S) synchronize twice (synchronization sessions 1 and 2). The anchor (9.9.2001, 09:09:09 AM) of the preceding synchronization session (which precedes synchronization session 1) related to the same databases is stored in the synchronization server S. This anchor was the contents of the Next anchor of the preceding synchronization session and was stored as the Last anchor for the first synchronization session 1. The client MS initiates synchronization session 1 on 10 Oct. 2001 at 10:10:10 AM. This time will be the Next anchor for synchronization session 1. The MS transmits the Last anchor stored in it and the Next anchor to the server S. During synchronization session 1 it is unnecessary to initiate slow synchronization because the Last synchronization anchors match, i.e. the Last anchor (9.9.2001, 09:09:09 AM) in the memory of the S corresponds to the Last anchor received. After the server S has transmitted an acknowledgement (OK), data can be synchronized. The acknowledgement is preferably an initialization message, which also comprises the Last and the Next anchor. After synchronization session 1 has finished, the S replaces the preceding Last anchor (9.9.2001, 09:09:09 AM) with the contents of the Next anchor (10.10.2001, 10:10:10 AM) in its memory. A transport failure occurs in the example, i.e. the MS does not update the Last anchor to its memory. The transport failure can be an error in the transmission connection, for example. The S can also disconnect the connection immediately after it has received a synchronization message, but the SyncML client can still remain waiting for an acknowledgement from the server. In that case disconnection is a transport failure from the SyncML client's point of view. During initialization of the second synchronization session the MS transmits a non-updated Last anchor (9.9.2001, 09:09:09 AM) and a Next anchor (11.11.2001, 11:11:11 AM) to the server S. The S notes that the Last anchors do not match, and thus it requests refresh, typically slow synchronization.
The problem related to the SyncML standard is that the update moment of the update identifiers which describe synchronization (synchronization anchor in the SyncML, e.g. a time stamp) has not been defined accurately. Depending on the manufacturer's application, some devices may update the identifier as soon as synchronization messages have been sent, whereas others perform this after the connection used for the synchronization session has been disconnected. As described in the example of FIG. 2, some devices do not necessarily update the identifier in an error situation, as a result of which slow synchronizations are performed needlessly. Slow synchronizations are particularly undesirable for the user because they take a lot of time and typically cause additional data transmission costs. The user may also think that synchronization failed because slow synchronization takes so much time.